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HP 300 Performance 


Choosing the right system with the right performance 
Capabilities is critical to the success of most applica- 
tions. To adequately evaluate a system, the system 
analyst needs to Know how much of the workload an- 
ticipated can be processed, and how quickly. To help in 
this evaluation and to demonstrate the range of perfor- 
mance available with the HP 300 Computer System, 
several comparable tests were conducted to measure 
throughput and response times for representative appli- 
cations. The information presented here is a collection 
of these measurements aimed at characterizing various 
key aspects of the performance of HP 300. (The goal in 
‘designing these tests was to duplicate the level of per- 
formance routinely attainable in normal application 
environments, rather than carefully selecting programs 
which would have given results better than those 
shown.) 


Configurations of HP 300 have been tested with main 
memory from 256 Kbytes to one Mbyte, and up to 16 
display terminals. This represents a broad range to 
select from in tailoring a system to meet current perfor- 
mance needs and in recognizing cost-effective growth 
paths for increasing future system demands. To ad- 
ditionally maximize success in implementing applica- 
tions on HP 300, system performance and applications 
design consulting is available from HP’s worldwide staff 
of System Engineers; and customer training courses 
with comprehensive documentation are offered at HP 
training centers. 


In the first section, Multiterminal Transaction Process- 
ing, measurements are presented for three application 
examples that are representative of the range of multi- 
terminal applications that are likely to be run on HP 300. 
The second section, Additional Performance Fundamen- 
tals, contains information on specific areas of process- 
ing performance that can be used in deriving a more 
complete approximation of HP 300 performance. The 
third section, Combined Processing Using Multi- 
programming, presents two multiterminal transaction 
processing programs and a lower priority set of opera- 
tions (including sorting, merging, printing, and data 
base access) all running concurrently. These tests dem- 
onstrate HP 300 in a representative environment which 
includes both multiprogramming and multitasking oper- 
ations. All tests were made using an HP 300 with the 
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standard built-in system disc. (Tests made using the HP 
7906 as the system disc instead, result in an average 
performance improvement of at least 15%.) 


Multiterminal Transaction Processing 


Each of the first three examples was implemented as a 
multitasking program following the recommendations 
given in the “HP 300 Multiterminal Applications Guide 
(31000-90005)”’ for developing efficient multitasking ap- 
plications. Each application was tested by itself on an 
HP 300 varying memory size and the number of termi- 
nals (each operated at 9600 baud). In each of these 
scenarios, user input times were chosen to be typical for 
the application but simulating a ‘‘worst case”’ situation 
where each user is performing at 100% efficiency. 


Example 1: Interactive Transaction Processing 

This example makes extensive use of the file system and 
other time and resource consuming sytem services. It is 
typical of many of the highly interactive applications that 
will be used on HP 300. The following form was 
displayed: 


Line Product 


Quantity Price 


As each line item was entered using this form, complete 
item information was constructed on the lower part of 
the same display by the system: 


Line Product 
001 TITTIA 


002 4444A 
003 55555B 


Operation U/M Quantity Price 


Wrightsons Air Filter EA 5 3.50 
C47-01 Gauge Rings DOZ 1 27.49 
Filter Paper, Blue PAK 2 1.75 


Transaction: The next line number was automatically dis- 
played in the form; after the user typed in the remaining fields 
and pressed the ENTER key, the product number was verified 
to be one that was present in a keyed sequential product file, 
numeric and alpha checking was performed on the fields and 
the price was verified to be within limits contained in the prod- 
uct file; all information for the line item was constructed from 
the product file and displayed, as well as being entered into a 
sequential transaction file (all files were appropriately locked 
and unlocked to allow shared access from multiple terminals); 
the fields in the form were then cleared, ready for the next 
transaction to be entered. (For the simulation, the interval be- 
tween clearing the fields and pressing the ENTER key varied 
randomly between 2 and 10 seconds at each terminal to simu- 
late typing time of an efficient operator.) 


Response Time: The interval between the time the ENTER key 


was pressed and the time the fields were cleared, ready for the 
next transaction to be entered. 


Response Time: Example 1 
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Display Terminals 
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Number of banks of memory 


For these complex transactions, performance remained 
favorable up through eight terminals. (For example, the 
average response time for eight display terminals 
operating simultaneously on an HP 300 having three 
banks of memory was 4.0 seconds. Adding a fourth bank 
of memory reduced the response time to 2.8 seconds for 
Example 1.) 
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Beyond eight terminals, response time increased to the 
point where each additional terminal added very little to 
the total number of transactions possible per hour. (This 
is made clear by the graph below of Total Transactions 
per Hour for Example 1.) Of course, if the average time 
delay between transactions were increased, a greater 
number of display terminals could be effectively used; 
however, the total throughput of transactions for the 
system would not increase significantly. 


Total transactions per hour: Example 1 


Number of total transactions per hour 
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Number of terminals 
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Example 2a: Simple Forms-oriented 

Transaction Processing 

This application example represents a high throughput 
test of multiterminal transaction processing on HP 300. 
It allows the maximum number of terminals that can be 
supported for any given memory size with fast response 
time and high transaction throughput. It is typical of 
many data entry applications (orders, inventory, cus- 
tomer information, etc.) where the need to access files is 
minimal at the input phase of the application. This dis- 
play form was used, and is representative of this type 

of application. 


Customer # 


Address Line #1 Address Line #2 


a # 


Customer Name 


ZIP Code 


Customer City State 


Credit Limit Salesman 


*One bank equals 128 Kbytes. The standard HP 300 has two banks, 256 
Kbytes; and can be expanded to eight banks, totaling one Mbyte. 


Transaction: Data was typed into each of the fields and the 
ENTER key was pressed; HP 300 performed limited checking 
on the fields; all fields were written into a sequential transac- 
tion file as a single entry; the fields were then cleared by HP 
300 making the form ready for the next transaction. (For the 
simulation, the interval from the clearing of the fields to the 
pressing of the ENTER key varied randomly between 20 and 50 
seconds at each terminal to simulate typing time of an efficient 
operator.) 


Response Time: The interval between the time the ENTER key 


was pressed and the time the fields were cleared, ready for the 
next transaction to be entered. 


Response Time: Example 2a 
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He display terminals 
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For simple forms-oriented transactions, these results 
show favorable response time through the maximum of 
16 display terminals. 


Example 2b: Simple Question and Answer Transactions 
This application example performed the same function 
as Example 2a, but was implemented instead as a series 
of questions and answers (one question and answer for 
each field). This is typical of the way many interactive 
applications have been implemented in the past. 


Response times were comparable to those presented for 
Example 2a and remained very favorable through the 
maximum of 16 terminals. (The total number of com- 
plete transactions that could be performed per hour is 
slightly less than for Example 2a due to the added time 
to display each question.) 


Example 3: Output Intensive Processing 

This example is representative of multiterminal applica- 
tions which require large quantities of information to be 
displayed. Inquiry applications that frequently display 
complete customer information, vendor orders, or 
inventory parts lists are examples of this kind of 
application. 


Transaction: A short inquiry was typed on the display and the 
RETURN key was pressed; a display full of information re- 
sulted, and the terminal was made ready for the next inquiry to 
be typed. (For this simulation, the interval from the time the 
display was full until the time the RETURN key was pressed 
varied randomly between 20 and 50 seconds to simulate 
reading and typing time.) 


Response Time: The interval between the time the RETURN 


key was pressed and the time that the screen was full, ready 
for the next inquiry to be typed. 


Response Time: Example 3 
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Number of banks of memory 


Range of Response Times: 

The Specific Application is the Key 

System performance in a transaction processing 
environment is the result of a combination of factors, 
including system hardware configuration and user ap- 
plication implementation. To provide a high perfor- 
mance system, Hewlett-Packard has optimized HP 300 
to allow maximum throughput and minimum response 
time. However, the factor that cannot be anticipated is 
your specific application. The application (or mix of 
applications) will determine the actual response time 
and throughput HP 300 will deliver. 


The range of HP 300 performance within two diverse 
application loads is illustrated below. The lower limit of 
the shaded area represents the average response time 
for a light application load. The transaction activity for 
this application involved simple forms-oriented data 


entry (Example 2). The upper limit represents a more 
demanding transaction load (Example 1). These transac- 
tions involved extensive file access to enter, inquire and 
update information (with locking and unlocking of 
shared files). Total memory size was increased along 
with the number of terminals, as indicated below, to rep- 
resent typical multiterminal configurations of HP 300. 


Response Time Range: Example 1 and Example 2 
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Additional Performance Fundamentals 

This section presents a wide range of additional HP 300 
performance characteristics. This information is useful 
in deriving more detailed approximations of total per- 
formance, which include the various activities typical in 
the day-to-day use of HP 300. 


Test 
HP 300 currently offers both Business Basic/300 and 
RPG II/300 compiler-based languages. Once a program 
has been entered, a single-key TEST function can auto- 
matically compile, segment, link and initiate a test 
execution of the program. (Program development is per- 
formed solely from the IDS on HP 300.) The time that it 
takes to perform this TEST function is indicated in the 
Program 


following tables: 
MEMORY (Total Number of Banks) 
Length 3 4 6 


1500 lines | 9:40 | 5:34 4:49 4:37 


TEST Time (minutes:seconds) 


Business Basic/300: 


RPG 11/300 MEMORY (Total Number of Banks) 


Program 
Length 


125 lines 


280 lines 


1060 lines 


TEST Time (minutes:seconds) 


These results show that increasing memory size to three 
and four banks improves TEST performance, and that 
TEST speeds are dependent on program size. 


These times were developed for HP 300 running the 
TEST function by itself. lf other computing were being 
performed concurrently, these times would increase. 
For example, the following results are from the TEST of 
the 200-line Basic program. At the same time, a multi- 
terminal application example was run at a higher 
priority. 


Concurrent Number of Terminals 


Application 


Example 1 


Example 2 


Time to TEST (minutes:seconds) 


Sort 

Business applications typically require large amounts of 
sorting in the processing of files. HP 300’s sort utility 
has the following performance characteristics. These 
tests used records that each contained 100 characters 
of data and were sorted by three keys (eight characters 
per key). 


No. of 
Records 


SORT Time (minutes:seconds) 


In these cases, only slight increases in performance 
were realized through the increase in memory size. Sort 
speed was dependent on the number of records being 
sorted. Sort speed is also dependent on record length 
as indicated by the following results. These sorts were 
run on an HP 300 having four banks of memory. 


R TH (i 
No. of RECORD LENGTH (in bytes) 


Records 


SORT Time (minutes:seconds) 


These times were developed for HP 300 running the Sort 
function by itself. If other computing were being per- 
formed concurrently, these times would increase. For 
example, the following results are for a 2000 record sort 
by three keys, using an HP 300 with four banks of 
memory. At the same time, a multiterminal application 
example was run at a higher priority. 


i a 


Concurrent 
Application 


Example 1 
Example 2 


SORT Time (minutes:seconds) 


Merge 

As one example of the Merge utility, two 2000 record 
files (100 characters per record) were merged using 
three keys. The resulting time to merge was 1.00 minute 
on an HP 300 with two banks of memory. 


File System 

The file system of Amigo/300 provides both sequential 
and keyed access methods. It also supports a wide 
range of file structures: sequential, relative, keyed 
sequential, direct, library, memory and primitive. The fol- 
lowing test results are representative of the general per- 
formance of the file system. All tests were made on an 
HP 300 with two banks of memory. 


Record Size (in bytes) 
Operation 
File Structure/Access Method: 


Sequential/Sequential 


Keyed Sequential/Keyed 
Direct/Keyed (500 Home Blocks) 


Time to Read/Write 1000 Records (in seconds) 


Print 

HP 300 currently supports up to two HP 2631 printers. 
The HP 2631 has a nominal speed of 180 characters per 
second, which varies slightly dependent on line length. 
In actual testing, the time required to print a 100-line 
report on HP 300 with an average line length of 

80 characters is 53 seconds. 


In running Example 1 with eight terminals and four 
banks of memory, the time required to print (with a 
lower priority) the same 100-line report increased to 3 
minutes and 28 seconds. 


Flexible Disc Transfers 

On an HP 300 having two banks of memory, the time 
required to write a file of information to the flexible disc 
and to read a file of information from the flexible disc 
tested as follows: 


Amount of Information 


38 Kbytes 
102 Kbytes 
384 Kbytes 


Time (in seconds) 


System Build 

System Build is used for reconfiguring the hardware and 
software of HP 300 and its attached peripherals. It is 
also used in the updating of system software. (Both of 
these functions are performed infrequently.) System 
Build operations are performed when there is no other 
activity on the system. A complete System Build for the 
updating of system software typically requires 2.5 hours 
(on an HP 300 with two banks of memory). Less time is 
required by System Build in reconfiguring hardware and 
software on an HP 300, dependent on the number of 
configuration changes being made. 


System Disc Capacities Available to Users 

HP 300 can have a built-in 12 Mbyte disc as its system 
disc. When the system software storage requirements 
are considered (including temporary additional storage 
needed by the system during such activities as TEST), 
approximately 7.3 Mbytes of storage remain for storage 
of user programs and data. (This figure assumes that all 
standard software as well as RPGII/300, Business 
Basic/300 and Image/300 are included on the system.) 


Using the alternative HP 7906 as the system disc instead 
of the built-in disc, changes user capacity to approxi- 
mately 14.9 Mbytes. Up to two other discs can optionally 
be added to HP 300. The HP 7906 (20 Mbytes), HP 7920 
(50 Mbytes), and HP 7925 (120 Mbytes) discs can be 
used, for a combination of up to 260 Mbytes of disc 
Capacity. 


During System Build an additional 4 Mbytes of tempo- 
rary disc capacity is used for construction of the new set 
of operating software. (A backup version of the operat- 
ing software could be left on the disc after System Build, 
but requires the additional 4 Mbytes.) On smaller con- 
figurations, it may be necessary to temporarily off-load 
user files and programs to make available the additional 
disc capacity needed by System Build. 


Typical Program Storage Requirements 

Figures are shown below for the typical program stor- 
age requirements of Business Basic/300 and RPGII/300 
programs in either a program development environment 
(i.e., all program files, including the source file, needed 
to develop, modify and run) or an execution only 
environment (i.e., only those files required to actually 
run the program; the source file and others are not 
included): 


Program 
Length 


200 lines 
1500 lines 


Business 
Basic/300 


RPG 11/300 125 lines 
280 lines 


1060 lines 


Storage Requirements (in Kbytes) 


Note that any requirements for data storage and tempo- 
rary files created by programs during execution are not 
included in these figures. 


Combined Processing 

Using Multiprogramming 

Example 1 and example 2 were run at the same time to 
give an indication of the effect on performance of run- 
ning different multiterminal applications at the same 
time. This was atest involving both multiprogramming, 
since example 1 and example 2 were each independent 
programs; and multitasking, since each of the terminals 
was run by a separate task with the example programs. 
In addition, as a test of greater processing concurrency, 
a standard job was defined and run as a batch job at the 
same time at a much lower priority. 


Test Criteria 
Throughput: To measure throughput, a standard job was used 
in all tests. It was made up of the sequential running of each of 
the following: 


e Execute program to print a 100-line report. 
® Sort a 2000 record file by three keys. 
e Merge two 2000 record files by three keys. 


e Execute a program to perform a representative mix of 250 
image/300 data base accesses. 
This job was run repeatedly throughout each test and the 
throughput calculated in terms of jobs per hour. Since the 
same job was used in all tests, it is valid to compare the 
throughputs of the various tests described here. Of course, 
users’ jobs would be different and would produce different 
throughputs when measured in these units. 


Response Time: The interval between the time the ENTER key 
is pressed to enter a transaction and the time that the user can 
begin to type the next transaction. The graphs show the aver- 
age response time for all terminals running each of the two 
Example transactions. (Terminals were run at 9600 baud.) 


Transaction Processing: Two types of interactive transactions 
were tested. The first used transactions that require more com- 
plex processing, making extensive use of file accesses and 
other system resources to verify and present information to the 
user (Example 1). The second used simple forms-oriented 
transactions to enter a full form of information into a sequential 
file (Example 2). 


Testing: The complex transaction (Example 1) was run contin- 
uously at a high priority on half of the terminals, while the sim- 
ple forms-oriented transaction (Example 2) was run at the same 
time with a lower priority on the other terminals. The standard 
jobs were run repeatedly as a still lower priority along with the 
transaction processing. Throughput for the standard jobs and 
response time for the terminals were measured. 


System: These tests were performed on an HP 300 using the 
built-in system disc. The total number of terminals was 
increased in pairs running the two transaction types as 
indicated by the graphs below: 


Response Time: Example 1 During Concurrent Processing 
with Example 2 and Standard Job 
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Number of 
isplay terminals 


Average response time (in seconds) 


Number of banks of memory 


Response Time: Example 2 During Concurrent Processing 
with Example 1 and Standard Job 


Number of 
display terminals 


Average response time (in seconds) 


Number of banks of memory 


Job Throughput During Concurrent Processing 
with Example 1 and Example 2 


Number of 
7 display terminals 


Throughput (jobs per hour) 
> 


2 3 4 5 6 7 8 
Number of banks of memory 


As the number of terminals (half of the terminals per- 
forming Example 1 and half performing Example 2) in- 
creases, the total throughput of the standard job, run- 
ning at a lower priority, decreases as shown in the graph 
above. (Running two standard jobs concurrently with 

no terminals on an HP 300 with four banks of memory, 
increased throughput from 6.7 to 9.2 jobs per hour.) 
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